1. Technical Field
The present invention relates to hardware accelerators for servers and, more particularly, to a content access memory (CAM) as an application hardware accelerator for accelerating string comparison operations in a server.
2. Description of the Related Art
As voice over Internet protocol (VoIP) continues to grow in popularity, there is a need to support session initiation protocol (SIP) applications and provide timely response times to simultaneous SIP dialogs in a server. Turning to FIG. 1, an exemplary server cluster is indicated generally by the reference numeral 100. The server cluster 100 includes and/or interfaces with a hypertext transfer protocol (HTTP) client 110, a layer 7 switch 120, and a plurality of servers 130. The layer 7 switch 120 includes a HTTP uniform resource locator (URL) routing module 122, a round robin routing module 124, and a network address translation (NAT) packet delivery subsystem 126. Each of the servers 130 includes HTTP applications 132 and a protocol-processing module 134.
A server cluster, such as that shown in FIG. 1, may be used to achieve scalability for transmission control protocol/hypertext transfer protocol (TCP/HTTP) applications. A typical server cluster may include a layer 7 switch as a front end to a set of servers at the back end. Both the layer 7 switch and servers may be SIP aware. The layer 7 switch may route the affiliate SIP packets to the same server.
In general, a layer 7 switch is a web switch that routes packets at the application layer (i.e., layer 7) of the Open Systems Interconnection (OSI) protocol stack. A layer 7 switch may perform content-aware routing and may establish a transmission control protocol (TCP) connection with a client and then receive a hypertext transfer protocol (HTTP) request at the application layer. A layer 7 switch may also be referred to as a content switch or a web switch.
A layer 7 switch may be used to route the service request from the client to one of the back end servers for serving the request. For some applications, every HTTP request is independent of each other. In this case, a round robin routing algorithm may be used to route and evenly distribute requests to the server. However, for other applications, there may be correlations among the sequences of the requests. In this case, a layer 7 routing algorithm may be used to route all these requests, which may be routed to the same server for processing. The layer 7 routing algorithm may be completely dependent on the application. For TCP/HTTP applications, algorithms that may be used include source Internet protocol (IP) address routing and session cookie routing. Some SIP applications may have to route all of the SIP packets of the same dialog to the same server, such that round robin routing is not appropriate.
Complicated string matching applications may also now appear frequently in the server environment. These applications and protocols may call for inspection of the packet payload at line rates to detect and filter packets that include desired large set of complicated strings. Some examples of such applications include, but are not limited to, virus detection, search engines, distillery applications, and so forth. The IP packet payload may be parsed to identify the positions and contents of key search strings. SIP protocol presents one example. Currently, a traditional software string parser and hash table performs the parsing. However, for some applications like SIP applications, the number of simultaneous packet payload inspection operations may be very large. Accordingly, the performance of software packet payload inspection operation is often too slow, and a mechanism is often needed to accelerate the speed.
SIP protocol can also makes layer 7 routing much more complex due to the fact that its transaction and dialog state is distributed and deeply inside the packet payload. Turning to FIG. 2, a typical SIP packet is indicated generally by the reference numeral 200. There may be several transactions in a lifetime of a SIP dialog. Each transaction may have its own unique transaction ID specified by the branch parameter of the current “via” header 202. Each SIP dialog is defined by 3 strings (Dialog ID): a Call-ID string; a From tag string; and a To tag string. The Call-ID string and the From tag string appear in the INVITE message by the caller as the beginning of a SIP dialog. The “To” tag string is filled by the callee in response to an indication to establish the SIP dialog. Subsequently, every SIP message belonging to this dialog may include this SIP dialog ID.
SIP is an extensive string matching operation and asynchronous protocol. Moreover, for a SIP Softswitch, a proxy server, and other application servers, it is possible to queue up millions of on-going SIP transactions/dialogs. As soon as a SIP request is created or a response is received in the SIP server, the server may have to search and match the packet payload strings out of the millions of session queues to identify the specified session and the state of the specified session. The current SIP implementation is to use the SIP transaction ID and dialog ID strings as a key to store the session state into a software hash table. However, the string parsing and comparisons often consume a large amount of CPU power and may not be able to handle a large amount of simultaneous SIP sessions. Moreover, a large number of entries in the hash table and a long string of keys can degrade the performance of the hash table. This may present a major speed bottleneck. Consequently, a hardware accelerator is needed for a SIP layer 7 switch as well as for SIP application servers.